[Win32] Improve pixel-to-point conversion precision #2718
Conversation
With recent changes to the rounding of pixel-to-point conversions the calculated sizes became too small in several use cases, leading to cut-off elements. This change adapts the rounding method to reduce the number of relevant cut-offs.
HeikoKlare
force-pushed
the
pixelToPoint-no-round-down
branch
from
ed21ba2 to
c2c78ac
Compare
| } | ||
|
|
||
| public static Point pixelToPointAsSize(Point point, int zoom) { | ||
| return pixelToPoint(point, zoom, RoundingMode.DOWN); |
There was a problem hiding this comment.
@HeikoKlare now as pixelToPointAsLocation and pixelToPointAsSize do the same thing, do we even need these separate methods?
There was a problem hiding this comment.
We do not necessarily need them, but we already embedded the distinction at all callers and we would of course still like to find a better concept for rounding the values, so to work on that it may be easier to keep the distinction for now. Otherwise, for the same reasons, you could also get rid of all the RoundingMode and just have a special handling for the case of computeSize().
|
Tested this changes at 125 and 175% zoom this seems to resolve the mentioned issue, when testing around I can also see the issee vi-eclipse/Eclipse-Platform#499 seems to be resolved for me at 125% zoom |
There was a problem hiding this comment.
Code looks good and the explanation makes sense. Tested it and it confirmed the observation from @arunjose696 for me
3 participants
With recent changes to the rounding of pixel-to-point conversions the calculated sizes became too small in several use cases, leading to cut-off elements. This change adapts the rounding method to reduce the number of relevant cut-offs.
Follow-up to:
How to test
Issues caused by pixel/point conversion roundings can best be seen at 125% or 175% monitor zoom.
Before at 125%:
After at 125%:
